In computer systems, there is typically some delineation between hardware units. Generally, there is some form of central processing unit and one or more connected peripherals. The central processing unit is often a general purpose computer such as a PC or server but it may be an application specific computing device such as a system on a chip (SOC). Peripherals are generally separate to the central processing unit (in some cases they may share a common power supply and in others they may have their own power supply) and are typically interchangeable. Peripherals may include input devices (such as user input devices, sensors, data network interfaces etc.) and output devices (such as display devices, printers, data storage devices etc.). Often, peripherals may have both input and output functions—for example a touchscreen display enables both input and output, likewise a storage device or network interface may be a source of input data or a destination for outputting data.
The delineation of units is intended to enable flexibility—the user or system implementer is not restricted by the hardware unit combination the manufacturer wishes to offer and can pick and choose the units, often from different manufacturers.
In order to support such flexibility, standards have arisen over time that dictate how units connect and communicate. Standards are often based around specific communication bus types, for example all USB compatible units must have appropriate USB connection ports and must be able to communicate over those ports using specific communication protocols.
Although peripherals are often physically remote from the central processing unit and connected by cables, for the purposes of this application this need not be the case and they may be directly connectable, for example by plugging into a hardware bus port on a motherboard etc. of the central processing unit.
Each hardware unit will generally require some form of initialization on start-up. This will vary depending on factors including the complexity of the device and also the functions it supports. A display, for example, will require less initialization than a touchscreen which has not only to deal with initialization of its display functionality but also that of its touch panel.
In order to maintain flexibility, it is common for the various peripheral units and their manufacturers to be responsible for their own initialization and provision of support for communication over the respective bus. How this is achieved varies a great deal and can depend on the approach favored by the manufacturer, the intended market and/or the system or operating system architecture used. Peripheral manufacturers are typically different to those manufacturing the central processing unit and its operating system. This means they may have to provider drivers or similar applications for execution by the central processing unit and its operating system to enable it to interact with the peripheral. Many peripheral manufacturers prefer to retain control and minimize developing drivers and the like. Their peripherals may include initialization routines in firmware in the unit Others, particularly those handling low cost and/or mass production peripherals may make them so generic that they can rely on routines are included as standard within the operating system, BIOS or firmware of the central processing unit.
One area where there is a great variance is in embedded display devices, that is, those designed as a component to be embedded within larger systems. While display devices typically provide the same basic functions, how they are initialized and driven varies. In some cases, the bus types supported dictate at least some of this (displays supporting HDMI or DisplayPort busses, for example, are likely to relatively consistent due to the prescribing nature of the respective standards). However, standardization and interchangeability is rarer in embedded display devices as an element of engineering is expected (and accepted) as part of constructing the larger system, incorporating driving routines for the embedded display device in the programming/firmware of the larger system so it can use the embedded display device. Embedded display systems vary widely in size, application and features. For example, a display in a mobile phone, ATM, vehicle entertainment system and video billboard would all typically fall under the definition of “embedded”.
In general, a display device typically has one or more controllers and/or driver circuits for proper control of the display device. Driver circuits, such as those used to drive a panel such as an LCD, for example, may be bonded directly to, and situated along the edge of the display panel itself. Alternatively, driver circuits may be mounted within the display device. In either case, the driver circuits are typically located at the display panel side of the interface with the computer system.
In order to initialize a display device, information on register settings is typically needed (most of which depend on physical properties of the panel used in the display device) as well as the display device manufacturer's prescribed power-up sequence (apply voltage, reset IC, hold reset, wait x amount of microseconds, release reset, etc.). In end-user display devices such as PC monitors, for example, these settings and steps are typically handled by routines encoded within the display device itself.
In end-user display devices such as PC monitors, mechanisms such as EDID, and its proposed successor DisplayID, may be provided by the electronics of the display device. These mechanisms use a ROM or PROM in the display to store a machine-readable description of the panel's capabilities. Once the display has been initialized, the EDID data can be obtained by the graphics system in the processing unit/computer system. EDID data typically includes manufacturer name and serial number, product type, phosphor or filter type, timings supported by the display, display size, luminance data and pixel mapping data. However, EDID is typically only available for recent end user display devices and is only available after initialization and so the panel initialization information still needs to come from somewhere. In the case of embedded display systems, EDID is typically seen as an unnecessary luxury—the embedded display device isn't going to be changed for another so the added expense and hardware overhead of providing such functionality is not incurred.
As can be seen from the above explanation, display information (via EDID or similar) and device-based initialization are provided in end-user display devices addressed by way of extra components in the display device.
However, extra components equate to extra costs and resources to house and implement them in the display device. In embedded display devices, these overheads are generally undesirable. Often, a display panel will be selected for use with as few supporting systems or circuits as possible to save on space and cost. Some commercial display panels use a driver integrated circuit (IC) that is a generic TFT panel driver such that the same driver IC may be used for different panel types. To keep the costs low, some of these ICs are based on SRAM technology.
Where the IC is generic, the register settings (refresh direction, analog voltages settings, gamma curves, etc.) have to be loaded at every power up. Hence, these kinds of panel need initialization after every power-up.
This is taken into account during implementation of the central processing unit and its systems—which are generally bespoke for the application in question. For example, a public announcement display may have specific a panel or panels that are driven by a bespoke central processing unit (or units) in which the panel's initialization code can be incorporated when the public announcement system is being developed. To minimize resource usage and costs further, many such systems are moving from general purpose PCs as central processing units to application specific system on a chip (SOC).